Companies typically use the World Wide Web to disseminate information both internally, to employees and contractors, and externally, to customers and business partners. This information is usually generated by content contributors or subject matter experts (SMEs), who are typically people with expertise in the information domain, but who are not usually technically skilled. In order to publish this information to the Web, or edit the existing information already on a company Internet or Intranet Web site, SMEs typically work with technically skilled Web professionals or Web developers, who generally combine Web coding or computer programming skills and graphics design and presentation skills. Skilled Web professionals or Web developers are an expensive and limited resource. Moreover, multiple Web professionals or developers may be used to obtain expertise in both the coding and graphic arts.
Web sites and Web pages typically comprise a Web server, that serves the visual and data content to the user's browser many times in a format, such as hypertext markup language (HTML), and a file transfer server, that provides read and write-access to the files that make up the visual and data content of the Web sites. While Web servers and file transfer servers are usually conceptualized as separate and independent machines, they, in fact, are typically software applications, which often time run on the same computer. The underlying Web files are usually stored on that computer or a storage device accessible by that computer, while the Web server and file transfer server interact with those files in different ways. Web servers typically allow read-only access to the files through HTML browsers, compared to the read/write-access usually allowed by the file transfer servers. Because file transfer servers typically allow read/write-access to Web files, general or non-skilled users are not typically given access because changing files through the file transfer server will usually change how those corresponding Web pages are served to the accessing browsers. Web professionals spend a great deal of time designing the core of the Web sites by using specific formatting or style sheets, relational dependencies between linked documents or pages, and the coding that creates dynamic Web experiences. Thus, full access to the inner workings of such Web sites and pages is usually limited to the technically-savvy Web developers to preserve the stability and operation of the Web site. In such cases, even where only minimal changes to the content or information is contemplated, the SMEs typically still work with the Web developers to implement those information changes. However, this solution is quite expensive relative to the amount of changes contemplated.
Alternatively, eschewing the dangers, SMEs may be given access to the file transfer server to make information changes. Existing Web development environments, such as MACROMEDIA, INC.'S DREAMWEAVER™, MICROSOFT CORPORATION'S FRONTPAGE™, and the like, allow anyone, including SMEs, to edit and eventually publish Web pages by themselves. However, these Web development environments are typically created for the technically knowledgeable Web developers, and, therefore, may be too technically complicated for SMEs to use easily or successfully. The existing Web development environments generally assume that the users know (1) where the underlying Web files are located in the file structure of the Web site; (2) how to configure the various protocols, such as file transfer protocol (FTP), secure FTP (SFTP), local area network (LAN), and the like, typically used to store and access those Web files; and (3) how to manage the uploading and downloading of the Web files. SMEs and other non-technical users typically do not have the technical knowledge or skill to find or successfully use this information.
Interaction between the file transfer server and the Web server is not always a direct one-to-one correspondence. In non-dynamic Web sites, a one-to-one correspondence typically exists between files accessed through the file transfer server and the URLs accessed through the Web site. In dynamic Web sites, a uniform resource locator (URL) may map to a differently-named or located file on the file transfer server. The file transfer server is typically run using a specific transfer protocol, such as FTP, SFTP, LAN, or the like. While the Web server delivers HTML content to requesting browsers, it uses hypertext transfer protocol (HTTP) to transfer the requests and resulting HTML content between the user's browser and the Web server. Even though both FTP and HTTP are both transfer protocols, they are designed for different purposes and are not necessarily compatible.
For example, the file management system for HTTP will generally be different than that of FTP. HTTP is designed for more limited, yet ready access than FTP. HTTP communications revolve around establishing communication between a browser and a Web server in which HTML documents and any supporting documents that correspond to an HTTP request are transmitted from the Web server (sometimes called an HTTP server) to the browser to be rendered to the user. An example HTTP request is: http://www.macromedia.com/index.html. The example request would likely be entered by a user into a Web browser. The http:// indicates the request is an HTTP request. The www.macromedia.com indicates the specific Web server domain to which the request is directed. Index.html is the specific file requested for display. Upon receiving this request, the Web server would typically communicate a read-only HTML file to the requesting browser for display. If a user were to enter a bare directory URL, such as http://www.macromedia.com/, an HTTP server would resolve the directory to the index file.
In contrast, FTP includes functions for logging onto the network, listing directories, copying files, and the like. An example FTP command is: ftp://user:password@ftp.macromedia.com. When entered in a browser, the ftp:// indicates that the request is an FTP request. The ftp.macromedia.com is the name of the FTP domain that the user wishes to log onto, and the user:password section is the user's password entry for logging onto the FTP server. Once logged on, the user can download and store files, view directories of the files on the FTP server and the like, depending, in general, on the level of authorization the particular user has for that particular FTP server. However, if the user were looking for the index.html file from the HTTP example, it would likely not be found if the user attempted to access ftp.macromedia.com/index.html. In actual use, the root directory of the file transfer server for www.macromedia.com would likely not be found in ftp://ftp.macromedia.com. For security reasons, the root directory would likely be found in a directory with a dissimilar name. The user would generally need to obtain the FTP path that corresponds to that particular Web site. Furthermore, if a bare directory address were entered, such as ftp://ftp.macromedia.com/, an FTP server will usually not resolve the requested directory to access the index file, as with the HTTP server.
In order to access the FTP server, a Web designer or developer is generally prompted by the server access application to provide the FTP host name, the FTP login, the FTP password, and the FTP path. While the FTP host name, login, and password are usually the pieces of information that will get the user onto the FTP server, without the FTP root path name, a user will not likely find the location on the FTP server where the underlying Web files are located. For most experienced designers or developers all of this information is relatively easy to know and/or obtain. A novice or non-technical user, such as a typical SME, may know the FTP host name, login, and password, but would generally not know the FTP root path; and, without the root path, the FTP server will generally not allow access to the appropriate file locations. Most novice users typically do not have even a basic knowledge of how URLs map to FTP paths. The Web master that manages the Web site could give this information to the SMEs. However, they are typically reluctant to do so since the possibilities for the SME to corrupt the Web site are usually great. Without knowledge of the FTP server system, it would be difficult for an SME to understand the location of the underlying Web files, and, thus, how to configure the various protocols or manage the uploading and downloading of the edited Web files. Having the Web developers assist in information updates or creating a customized system for updating information each offer expensive solutions to the Web development lifecycle.
In order to increase the ease of Web development and maintenance, Web development environments have advanced to automate or abstract some of the more technically oriented tasks involved in Web design and publishing. NETSCAPE COMMUNICATIONS CORPORATION's COMPOSER™ implemented a browse-edit paradigm of Web maintenance. Most individuals are comfortable and experienced with the concept and act of browsing. Using COMPOSER™, a user could browse to a particular Web page that he or she desired to edit and click an “Edit Page” button to edit the underlying Web source file. If all of the authorizations and addresses were previously set up, COMPOSER™ would open a separate window with the underlying source file of that Web page. The user could then edit that file and save it locally for possible uploading back to the Web site through its FTP. MICROSOFT CORPORATION's INTERNET EXPLORER™ also includes a version of the browse-edit paradigm. On selection of an “Edit in FrontPage” button, INTERNET EXPLORER™ starts an instance of MICROSOFT CORPORATION's FRONTPAGE™ in a separate window with the Web page file to be edited, again, if the authorizations and file addresses were already set up in advance. Both of these Web development environments allow the user to edit the Web page and store it locally for future action. However, in order to upload the modified Web page to the Web site, the file still needs to be communicated to the Web site through its file transfer server, typically by a Web developer. Therefore, while the browse-edit paradigm streamlines the editing process, the limited amount of editing available to the SME still needs to be uploaded by a Web professional.
Moreover, the browse-edit paradigm, of COMPOSER™ and FRONTPAGE™, provides a solution for simple Web pages that do not have complex dependencies and links. These development environments are not capable of automatically handling the complex document dependencies and links found in most Web pages. Furthermore, COMPOSER™ and FRONTPAGE™ typically may only edit existing pages in the browse-edit paradigm implementation. Because of their deficiencies in handling the links and dependencies, when pages are added or deleted to a Web site, COMPOSER™ and FRONTPAGE™ generally do not automatically update and amend the dependencies and links of the other related pages in the Web site that may need to be updated to either add the new page or delete references to the deleted page. The browse-edit paradigm practiced by COMPOSER™ and FRONTPAGE™ simply does not have the capability to modify Web pages other than the actual page being edited.